Currently, numerous data processing systems and applications, herein referred to collectively as data processing applications” or “applications”, are available to help users organize and process data. Examples of data processing applications include, but are not limited to, accounting and/or bookkeeping applications, tax preparation applications, healthcare expense tracking applications, docketing applications, etc.
Many of these data processing applications are used by “professional” users to create, organize, and store, multiple files, and/or documents, often for multiple clients, and/or for multiple projects. For instance, as one example, accountants often use a single accounting and/or bookkeeping application to create documents, files and/or folders for multiple different clients.
When a professional user implements a data processing application to obtain, receive, create, organize, and store, multiple documents, and/or files, for multiple clients, and/or for multiple projects, it is often critical that the user maintain an accurate listing of all of their client's, or active client's, and/or projects, and all of the files, and/or documents, associated with the user's clients, and/or projects. However, most users of data processing applications create their own unique data management and organizational scheme or structure to store files and documents in a data storage system, such as on/in one or more disk drives/hard drives, network drives, memories, etc., and these data management and organizational schemes are often redundant, spread across multiple data storage system locations and/or data storage systems, and often reflect the user's unique sense of order and structure which may, or may not, be intuitive to others.
For instance, it is typical for a user of a data processing application to save files, and/or documents, in data storage system memory locations/folders having names based, at least in part, on the name of the associated client or project. However, in addition, users of data processing applications often also save these files, and/or documents, in other data storage system memory locations/folders having names based on the version of the data processing application associated with the files, and/or documents, to help identify the files, and/or documents. In addition, the files, and/or documents, are often of different file, and/or document, types such as, but not limited to: a company file, and/or document; a backup file, and/or document; an account file, and/or document, etc. Therefore, in some cases, the user saves these files, and/or documents, in yet another set of memory locations/folders with names based on the type of file, and/or document, to be stored.
As a more specific example, it is often the case that an accountant using an accounting/bookkeeping application saves all the user's clients' files as data in a memory system, such as a hard drive, accessible by the accountant's/user's computing system. In addition, it is often the case that the accountant/user employs a data organizational scheme whereby a folder is created for each of the accountant's/user's client's files, and/or documents. In addition, the accountant/user may have clients using two or more versions of the accounting/bookkeeping application and, therefore, the accountant/user has folders for files, and/or documents, associated with each version of the accounting/bookkeeping application and/or sub-folders underneath the folders for each client. In this example, the accountant/user would typically name the folders, and/or sub-folders, after the client's name or their business name, or the associated project, and would likely also maintain both the current and older versions of the accountant's/user's clients' files, and/or documents, under a folder for each accounting/bookkeeping application version.
In this specific illustrative example, the result is that a given client's files, and/or documents, will often reside in multiple memory locations, and perhaps in multiple data storage systems. As a result, currently, it would be extremely difficult for the accountant/user to collect and correlate the client files, and/or documents, and use them to identify and/or create a client or project list, or identify, much less list, all the files, and/or documents, related to a specific client and/or or project. It would currently be even more difficult, if not impossible, to display the different types of files, and/or documents, and/or see how files, and/or documents, for a given client and/or project may be related to files, and/or documents, associated with other clients and/or projects.
In short, as discussed above, the fact that different users of data processing applications utilize different data storage and organization schemes, largely custom created by the users, to store files, and/or documents, means that currently it is often very difficult to automatically create accurate client lists and/or group/display files, and/or documents, for either a given client or project. Consequently, logical data grouping, display, and analysis is extremely difficult and must currently be performed largely on a manual basis. However, despite the difficulties created by their individual data storage and organization schemes, most users of data processing applications prefer their own data storage and organization schemes and do not want to have the actual data associated with their client's files, and/or documents, moved out of the data's current physical memory location, or have any changes made to their own underlying data organization and storage system.
What is needed is a method and system that allows for the automatic creation of client lists and listings of related files, and/or documents, that is based on actual data, files, and/or documents, and provides for various types of file listings and displays, all without physically changing the current memory location of the data representing the files, and/or documents, or making any changes to user's existing underlying data storage and organization system/scheme.